BREAKING CHANGE for 2019.2.21 - 2019.2.22
$where in Workflow Engine API Calls
Due to a vulnerability with Mongo, the $where key is no longer supported as part of the query object for several API calls. The $where key is specifically used in Mongo to support a JavaScript expression or function to be used as part of a query. Any APIs that were vulnerable to the usage of $where will now return with an error if $where is included in the query. The following APIs are affected by this, with the relevant parameter noted for each.
| API | Parameter |
|---|---|
| POST /workflow_engine/getJobFromTaskQuery | task_query |
| POST /workflow_engine/queryJobs | query |
| POST /workflow_engine/jobs/find | query |
| POST /workflow_engine/queryTasksBrief | query |
| POST /workflow_engine/getTask | query |
BREAKING CHANGE for 2019.2.11 -> 2019.2.12
This section outlines specific changes to note when upgrading from the 2019.2.11 maintenance patch to the 2019.2.12 patch. Technically, these are considered non-breaking changes; however, Itential decided to place the information here for convenience and to support customers as they upgrade.
RabbitMQ Properties Moved from Service Config to Profile
Upon upgrade to the 2019.2.12 maintenance bundle, the RabbitMQ properties will be automatically moved from all service configs to the profile. Additionally, these settings will be changed in the database; therefore all systems that share this database connection will be affected also. Please note, if you have a disaster recovery (DR) system in your setup, the changes made to the database will take effect once the first system is updated and affect all systems using that database. This basically means that all systems will need to be upgraded at the same time.
Rollback Instructions
Since the RabbitMQ properties will be auto-migrated from the service config to the profile, if a rollback is necessary, those properties must be restored manually to each relevant service config prior to upgrade.
BREAKING CHANGE for 2019.1 -> 2019.2
The following is a breaking change for the 2019.2 distribution of Itential software.
app-number isNaN task and api are removed
The isNaN task and API call has been removed from IAP 2019.2 due to an inability to pass in JS objects like NaN, Number.NaN, and 0/0. Anything that can be passed in this method through REST API or the workflow task will evaluate as false, thereby rendering the task pointless.
Corrected Workflow Engine Job Variable Validation
Versions of the Workflow Engine prior to the 2019.2.4 maintenance release contained a job variable validation flaw that prevented the user from being prompted for certain required job variables.
We have corrected this issue and now all required job variables must be supplied when a workflow is started, either from the UI or from the startJobWithOptions API.
If your workflows contain either of the following two scenarios, you will need to correct the workflows before promoting this maintenance release to a production environment.
Please note that each scenario outlined below is now being properly validated.
The first scenario involves two tasks connected by a failure transition.
The first task registers a job variable when the task errors.
The second task (connected by a failure transition) is attempting to consume the job variable; however, since the task emitted an error instead of a failure, the job variable has never been set.
Previously, the job would have started and failed if this particular transition were reached. Now that the job variable validation has been corrected, the job will not start without the variable provided as input.
To correct this issue, review the transitions between the two tasks and assess the following solutions.
Transition Solution The transition was erroneously built as a failure transition instead of an error transition. Change the transition to an error transition. The failure transition is correct and the job variable value should be provided by some other task in the workflow. Identify the task that should provide the job variable value. Both the failure transition and the job variable were built correctly. The job variable value will need to be provided by the initiator of the job. The second scenario involves a task which self-references a job variable in both the input and error screens.
The View Data task is consuming the job variable as input.
The same job variable is produced by the task on the error transition.
If this job variable is not defined anywhere else in the workflow, the validation should now properly fail and prompt the initiator to provide a value for the variable.
To correct this issue, review the workflow for usage of this job variable. Identify the task that is meant to produce a value for the variable.
If no such task exists, use the
newVariabletask to provide a default value for the variable.
Note: The two tasks used in the scenarios are example tasks (getDevice and ViewData). The description of this issue is not specific to these two tasks but rather applies to any workflows that use job variables in the ways described above.
app-automation_catalog
Changed the structure of the group based access (GBAC) property from a single array of group IDs to a property containing read and write arrays. These new arrays contain group objects instead of IDs. No migration script is needed as legacy GBAC properties are converted on start up. A message will be logged on startup if any document modification is performed.
app-configuration_manager
Changed getDevicesFiltered to now require the 'limit' property. Previously if the 'limit' property was not provided or if 'limit=0' then the result would yield all devices. If there were a high number of devices, then this would cause timeouts or exception errors. For system integrity, we have removed the capability to list all.
app-template_builder
New Format of Jinja2 Templates Prior to Maintenance Release 2019.2.4
Although many will view this as an improvement, for those who have been using this relatively new feature, we would be remiss if we did not notify you of this change. In maintenance release 2019.2.4, the template provided in the Template Builder user interface no longer requires an opinionated reference to the 'data' variable. Before the change, you could supply any JSON, and then reference it in the template as "data.whatever." After the change, you can only supply a JSON object, and you no longer need to use the data prefix in the template. You can just reference the object properties identified in the JSON object by name directly. We feel this ease of use improvement warrants a change notice and aligns with the overall user experience within our product. We also hope to have caught this early enough to not have caused too much rework. If you have any templates built before the 2019.2.4 maintenance release, please update them as well as their corresponding JSON data object to match the new interface.
Tags Application
Database ID is Stored as ObjectID
In previous versions of the Tag application, the ID column was stored in the database as a string. In this release and beyond, the ID will be stored in the database as an ObjectID (see reference below for ObjectID). Applications that rely on database queries utilizing the ID column must now use the ObjectID instead of an ID string.
Reference: MongoDB ObjectID
New IAP Architecture Component - RabbitMQ
Requirements
RabbitMQ is now required to run Itential Automation Platform (IAP). Please follow these instructions to update your installation: RabbitMQ Installation.
Once RabbitMQ is installed please follow the upgrade instructions: IAP Upgrade.
After the migration script has completed there are a few changes to be aware of:
- Many of the properties from the properties.json file have been moved to the Mongo database, so the file will be much smaller.
- Two new tables will be created in the Mongo database: iap_profiles and service_configs. These will hold IAP and service related information.
- The properties from the properties.json file can now be accessed in the Profiles and Services section of the Settings menu.
- Global data and settings can be found in the Settings menu as Profiles, while service specific data and settings can be found in the Settings menu as Services.
References
More information is available at the following links: